Closed Bug 300207 Opened 19 years ago Closed 18 years ago

Scrollbars in ClearLooks theme do not have rounded corners

Categories

(Core Graveyard :: GFX: Gtk, defect)

x86
Linux
defect
Not set
trivial

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: spikes.phone_0t, Assigned: blizzard)

Details

Attachments

(1 file, 3 obsolete files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050709 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050709 Firefox/1.0+

ClearLooks draws rounded corners on its scrollbar buttons. It determines whether
to draw left/top buttons or right/bottom ones by examing the allocation member
of the GtkScrollbar it is drawing. Because the scrollbars passed to gtk_draw_box
have their default allocations, this test always fails and the default,
non-rounded box is drawn.

Reproducible: Always

Steps to Reproduce:
1. Run Firefox/GTK2 with ClearLooks as the theme
2. Examine the scrollbars

Actual Results:  
The scrollbars have sharp corners.

Expected Results:  
The scrollbars should have rounded corners.
Attached patch Attempt at fixing the problem (obsolete) — Splinter Review
This modifies the allocation so that the ClearLooks theme draws correctly. It
doesn't appear to break any of the other GTK+ themes I've tried, but it does
modify the global scrollbar variables, which might be bad (I'm just getting
aquainted with the source).
(In reply to comment #1)
Oh, and yes this is rather hackish. :-)
Attachment #188782 - Attachment is obsolete: true
Attached patch Less hacky scrollbar patch (obsolete) — Splinter Review
Create an allocation for the scrollbar to please the themes that care
Assignee: nobody → blizzard
Component: General → GFX: Gtk
Product: Firefox → Core
QA Contact: general → gtk
Version: unspecified → Trunk
Similar to bug 206554. You need to request a review from someone on your patch
for anything to happen. Either roc or pav would probably be suitable here.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attachment #188799 - Flags: review?(pavlov)
Attached patch Respin of previous patch (obsolete) — Splinter Review
This is a respin of the previous patch against HEAD that was sent to me.
Attachment #188799 - Attachment is obsolete: true
Attachment #204488 - Flags: review?
Attachment #188799 - Flags: review?(pavlov)
Attachment #204488 - Flags: review? → review?(roc)
Attachment #204488 - Flags: review?(roc) → review?(bryner)
Attachment #204488 - Flags: review?(bryner) → review+
I checked this in.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
The up and left arrows are rounded, but the down and right arrows are still stupid rectangles.

Maybe this is because I use the following UserChrome.css-rule to make the additional up/left-arrow visible, but I didn't tested it without them. 

scrollbarbutton[sbattr="scrollbar-up-bottom"] {display: -moz-box !important;}
The bug appears also without the UserChrome-Code. Up- and left-arrows work fine, but down and right-arrows are still rectangular.
Comment on attachment 204488 [details] [diff] [review]
Respin of previous patch

Low-risk patch, baked on trunk, and would be good UI polish for branch.
Attachment #204488 - Flags: approval-branch-1.8.1?(roc)
Attachment #204488 - Flags: approval-branch-1.8.1?(roc) → approval-branch-1.8.1+
Please look at Bug 336270 first.

No rounded corners may be better than incorrectly rounded corners. IMHO.
This one should fix the problem with the right/bottom steppers not being rounded. Double steppers (e.g. in Clearlooks-NeXT) don’t renderer properly (the inner ones should not be rounded), but it’s not immediately obvious whether one can know if he should drawn an inner stepper or not. I’m also not sure why using three times the stepper size for the fake allocation works but double doesn’t; maybe someone better versed in the peculiarities of GTK+ would know.
Attachment #204488 - Attachment is obsolete: true
Yeah, I just figured out independently that using triple the button size worked but double (as the current code does) doesn't.

That said, I think the patch belongs in bug 336270.

What's the difference between what button_rect and *rect represent ?  In my build, they're always the same, and the code doesn't really help me understand what they're supposed to be.  Did which one you used make a difference for you?
(My gut feeling is that the code using rect is probably more likely to be correct.)
...followup discussion should probably go on bug 336270; putting things in already-fixed bugs is a good way to get them lost.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: